Cloudflare WARP でリモートからドメインサフィックスを補完する
2024.08.30Cloudflare WARP と cloudflared を組み合わせて使うと、リモートアクセスVPNと同様の体験を得ることができます。
一方で組織のイントラネットを管理する上で、オンプレAD等のドメイン環境を利用している場合も多いかと思います。
そういった環境では、社内にいる場合、ドメインサフィックスを使って、ホスト名だけで通信を行っているのではないでしょうか。
リモートから社内のリソースにアクセスする時に、これと同様の接続体験を得るために、ドメインサフィックスを補完してホスト名だけでアクセスできるようにしたいと思います。
構成
下記のような構成です。
前提として、Cloudflare WARP では、現時点では、WARPが作成するバーチャルインターフェイスへは、ユーザー側で個別にインターフェイス設定を変更することはできません。
そのため、WARPインターフェイスにはドメインサフィックスを追加することはできない仕様になっています。
Resolver Policies と DNS Policies を使ってドメインサフィックス補完の動作をシミュレートする
Cloudflare Zero Trustの異なる２つのポリシー（機能）を使って、ドメインサフィックスを補完します。
まず1つ目は Resolver Policies です。
これは、Local Domain Fallback と同等の機能を提供します。
ただし、Local Domain Fallback は、対象のドメインの名前解決をCloudflareに通さず、ローカルのDNSリゾルバサーバーに問い合わせをするのに対し、Resolver Policies では、対象のドメインをCloudflareに一度通し、DNS Policies でルールの評価をしたり、Cloudflare上でロギングをした後、ローカルのDNSリゾルバサーバーに問い合わせる動きをします。
※Resolver Policies は、現在Enterprise Planでのみ利用可能です。
2つ目は DNS Policies です。
こちらは、カテゴリブロックや、セーフサーチ、ドメインの書き換えができます。
今回ドメインの書き換えを応用します。
どのようにドメインサフィックスを補完してホスト名だけで社内ドメインにアクセスさせるか簡単なシーケンスです。
PC -> ホスト名だけでアクセス -> DNS Policies でドメインサフィックス付きのFQDNに書き換え -> Resolver Policies でFQDNをローカルのDNSリゾルバサーバーへ -> ローカルのDNSリゾルバサーバーで問い合わせ -> 社内リソースへアクセス
なぜこういう動きになるかのCloudflare側の動きは、こちらのブログで詳しくご紹介されていますので、ぜひご参照ください。
Resolver Policies 設定
※本設定の前にLocal Domain Fallback の設定に対象のドメインが含まれていないことを事前に確認しておいてください。localやinternalなどがデフォルトで設定に入っているので対象のドメインにこれらが含まれている場合は注意が必要です。
Resolver Policies で追加をします。
ローカルのDNSリゾルバに問い合わせたいドメインを指定します。
ローカルのDNSリゾルバのIPを登録し、保存します。
DNS Policies 設定
Firewall Policies の DNS で追加をします。
アクセスする時のホストを指定します。
ActionにOverrideを選択して、FQDNを設定して、保存します。
設定反映に少し時間がかかるときがあるので、少し待ちます。
テスト
今回 Mac の環境で、ドメイン環境で動くDFSに対してホスト名だけでアクセスできるか確認してみました。
dc へはDNSサフィックスがつかず、当然名前解決ができていません。
$ dig dc a
; <<>> DiG 9.10.6 <<>> dc a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 33435
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;dc. IN A
;; AUTHORITY SECTION:
. 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2024082902 1800 900 604800 86400
;; Query time: 25 msec
;; SERVER: 127.0.2.2#53(127.0.2.2)
;; WHEN: Fri Aug 30 07:40:17 JST 2024
;; MSG SIZE rcvd: 119
dfs_server へは一度CNAMEが引かれ、IPアドレスが返されていることが分かります。
$ dig dfs_server a
; <<>> DiG 9.10.6 <<>> dfs_server a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26776
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;dfs_server. IN A
;; ANSWER SECTION:
dfs_server. 60 IN CNAME dfs_server.sakai.local.
dfs_server.sakai.local. 1200 IN A 172.31.39.88
;; Query time: 126 msec
;; SERVER: 127.0.2.2#53(127.0.2.2)
;; WHEN: Fri Aug 30 07:38:18 JST 2024
;; MSG SIZE rcvd: 91
サーバーに接続してみます。
Finder で「移動」、ホスト名だけを指定して「サーバへ接続」でアクセスします。
アクセスが出来ました。
Windowsの場合だと、ドメインに参加するとプライマリDNSサフィックスが設定されるので、あまり今回のユースケースを活用する出番が少ないかもしれません。
ただ、プライマリDNSサフィックスでない親のドメインや、その他の派生したドメインへのサフィックスが必要となる場合は同様のユースケースが適用できるのではないかと思っています。
まとめ
ドメインサフィックスのように、全てのアクセスに対して、サフィックス付きの接続を試してみるなどの動きにはできないですが、ホストごとで設定してアクセスができることが確認できました。
この記事がどなたかの一助になれば幸いです。
